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(54) Method and apparatus for trusted processing 



(57) Trusted processing capability, for example for a 
cryptographic unit element in an International Cryptog- 
raphy Framework, secures one or more tasks or proc- 
esses associated with application code. Trusted 
processing is assured by a trusted element, where use 
of the trusted element is based upon the principles of 
separation and locality, i.e. where the trusted element is 
associated with a trusted computing base that is sepa- 
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rated from the operating system and/or data by a trust 
boundary, and where protected mechanisms are used 
to access the trusted element such that trusted execu- 
tion occurs only locally in a trusted execution area. The 
trust processing capability also encompasses a policy 
controlled main CPU 
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Description 

BACKGROUND OF THE INVENTION 

TECHNICAL FIELD 5 

The invention relates to trusted processing. More 
particularly, the invention relates to a method and appa- 
ratus that provides a trusted element that assures 
trusted processing within an international cryptography io 
framework or other processing environment. 

DESCRIPTION OF THE PRIOR ART 

Customers of large computer systems are typically is 
multinational corporations that want to purchase enter- 
prise wide computer based solutions. The distributed 
nature of such organizations requires them to use public 
international communications services to transport data 
throughout their organization. Naturally, they are con- 20 
cerned about the security of their communications and 
seek to use modern end-to-end cryptographic facilities 
to assure privacy and data integrity. 

The use of cryptography in communications and 
data storage is governed by national policy and urrfortu- 2s 
nateiy, national policies differ with respect to such use. 
Each national policy is developed independently, gener- 
ally with a more national emphasis rather than interna- 
tional considerations. There are standards groups that 
are seeking to develop a common cryptographic algo- so 
rfthm suitable for international cryptography However, 
the issue of international cryptographic standards is not 
a technical problem, but rather it is a political issue that 
has national sovereignty at its heart. As such, it is not 
realistic to expect the different national cryptography 35 
policies to come into alignment by a technical standard- 
ization process. 

The issue of national interests in cryptography is a 
particular concern of companies that manufacture 
open-standards-based information technology products 40 
for a worldwide market. The market expects these prod- 
ucts to be secure. Yet, more and more consumers of 
these products are themselves multinational and look to 
the manufacturers to help them resolve the international 
cryptography issues inhibiting their worldwide informa- 45 
tion technology development. The persistence of unre- 
solved differences and export restrictions in national 
cryptography policies has an adverse impact on interna- 
tional market growth for secure open computing prod- 
ucts. Thus, it would be helpful to provide an so 
international framework that provides global information 
technology products featuring common security ele- 
ments, while respecting the independent development 
of national cryptography policies. 

Nations have reasons for adopting policies that ss 
govern cryptography. Often these reasons have to do 
with law enforcement and national security issues. 
Within each country there can be debates between the 



government and the people as to the Tightness and 
acceptability of these policies. Rather than engage in 
these debates or try to forecast their outcome, it is more 
practical to accept the sovereign right of each nation to 
establish an independent policy governing cryptography 
in communication. 

Policies governing national cryptography not only 
express the will of the people and government but also 
embrace certain technologies that facilitate cryptogra- 
phy. Technology choice is certainly one area where 
standardization can play a role. 

However, as indicated earlier this is not solely a 
technical problem, such that selection of common cryp- 
tographic technologies alone can not resolve the 
national policy differences. Consequently, it would be 
useful to provide a common, accepted cryptography 
framework, wherein independent technology and policy 
choices can be made in a way that still enables interna- 
tional cryptographic communications consistent with 
these policies. 

A four-part technology framework that supports 
international cryptography, which includes a national 
flag card, a cryptographic unit, a host system, and a net- 
work security server is disclosed by K. Klemba, R. Mer- 
cWing, International Cryptography Framework, in a 
copending U.S. patent application serial no OS/401 ,588. 
which was filed on 8 March 1995. Three of these four 
service elements have a fundamentally hierarchical 
relationship. The National Flag Card (NFC) is installed 
into the Cryptographic Unit (CU) which, in turn, is 
installed into a Host System (HS). Cryptographic func- 
tions on the Host System cannot be executed without a 
Cryptographic Unit which itself requires the presence of 
a valid National Flag Card before it's services are avail- 
able. The fourth service element, a Network Security 
Server (NSS), can provide a range of different security 
services including verification of the other three service 
elements. 

The framework supports the design, implementa- 
tion, and operational elements of any and all national 
policies, while unifying the design, development, and 
operation of independent national security policies. The 
framework thus gives standard form to the service ele- 
ments of national security policies, where such service 
elements include such things as hardware form factors, 
communication protocols, and on-line and off-line data 
definitions. 

Critical to the implementation of the framework is 
the provision of a fundamental technology that allows 
the production of the various service elements. While 
various implementations of the service elements are 
within the skill of those versed in the relevant art, there 
exists a need for specific improvements to the state of 
the art if the full potential of the framework is to be real- 
ized. 

One issue of importance in the framework and 
other trusted systems is that of composition, i.e. where 
each and every element of the trusted system must be 
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trusted, because a system composed entirely of trusted 
elements is both cumbersome and slow. It is therefore 
desirable to provide only the number of trusted ele- 
ments that are necessary to assure that the level of 
desired trust is provided. 5 

Trusted products require the arrangement of some 
properties into secure systems to be composable. Such 
properties are preferably provided in accordance with a 
predefined standard. For example, it is necessary to 
determine the kinds of relations the trusted elements of io 
the framework bear to one another, tt is also necessary 
to define the security relevant properties of trusted ele- 
ments when they are engaged in such relations. It is fur- 
ther necessary to determine what inferences may be 
drawn about the security relevant properties of a com- is 
posed system from the security relevant properties of 
the system's constituent elements, i.e. can the trusted 
element be defeated with knowledge derived from other 
elements of the system. 

Accordingly, it would be advantageous to define 20 
and implement a trusted processing function within the 
confines of the framework or other processing system. 

SUMMARY OF THE INVENTION 

25 

The international cryptography framework allows 
manufacturers to comply with varying national laws gov- 
erning the distribution of cryptographic capabilities. In 
particular, such a framework makes it possible to ship 
cryptographic capabilities worldwide in all types of infer- so 
mation processing devices {e.g. printers, palm-tops). 
Within the framework, a cryptographic unit contains sev- 
eral cryptographic methods {e.g. DES. RSA, MD5). 

The invention provides a trusted processing ele- 
ment, for example in an international cryptography ss 
framework or other trusted processing application. For 
purposes of the disclosure herein, the element of trust is 
defined in accordance with 1SO/IEC 10081-1, i.e. where 
element x trusts element y for some classes of activity in 
the context of a security policy, if and only if element x ao 
has confidence that element y behaves in a well-defined 
way that does not violate the security policy. 

The invention provides a method and apparatus 
that solves the problem of composition by providing a 
trusted computing base that is accessed by an applica- as 
tion having a limited number of trusted execution 
streams. Such execution streams are easy to con- 
trol/define as trusted. The architecture of the invention 
defines simple relationships between those areas which 
are considered as trusted versus those that are exe- so 
cuted. 

The trusted processing element is implemented in 
accordance with various principles, including: 

• Separation • At any level of execution, clean sepa- ss 
ration of the security functionality from other func- 
tionality is employed to minimize the amount of 
functionality that must be trusted and therefore 



increase the level of trust that can be achieved. 
Hence, at one extreme end of the spectrum there is 
a singular execution of the instruction. Practically, 
systems or kernel implementations refer to an 
atomic execution element as a single task or 
thread, and protected interprocess communication 
mechanisms. 

Thus, to execute in a trusted zone or area, it is nec- 
essary to have insurance of confidentiality of com- 
partments. The compartments represent 
executable code or a combination of code and data. 
Thus, the principle of separation provides a first 
step for implementing trusted execution, which is 
that the system must have compartment areas 
where the execution streams are used to pass exe- 
cutable code to the trusted computing base. This, 
principle leads to confidentiality in a system, but the 
separation principle is not sufficient to fulfill integ- 
rity. 

Locality - Any part of a system that is permitted to 
process information is able to corrupt that informa- 
tion. Therefore, preserving the integrity of the infor- 
mation depends on the level of trust of the 
constituent parts of the system that handle the 
information, ff the data or instructions are executed 
locally, the trust element only has control of the 
information within the trust boundary, i.e. it has no 
control outside and vice versa There is by defini- 
tion a tack of trust outside of the partition estab- 
lished by the trust boundary because, once the 
information is outside of the compartment, it is free 
to participate in untrustworthy executions. Thus, the 
invention implements the principle of locality, i.e. 
executions that are related to processes or tasks in 
the partition are operated upon only locally in the 
trusted computing base. 

As an application of the first principle, the trusted 
processing capability of a cryptographic unit as 
controlled by a policy card, becomes a trusted exe- 
cution area where critical applications transform 
sensitive information. Such information uses pro- 
tected mechanisms, i.e. envelopes, to leave the 
trusted execution area or to join the user level task 
before local execution by the cryptographic unit. 

Within the trusted processing element (for example, 
as applied to a cryptographic unit), the main CPU partic- 
ipates in processing trusted partitions that are control- 
led by the policy. 

Fundamental properties of the trusted processing 
element include: 

• Encapsulated single tasks; 

• Use of closely coupled, reconf igurable kernel com- 
ponents; and 
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security privilege execution, in the context of a per- 
sonal token and trusted processing according to the 
invention. 

5 PETAILED DESCRIPTION OF THE INVENTION 



Execution of adaptation policies in a secure vault to 
prevent unauthorized uses of privileges. 

Thus, the trusted processing element provides a 
trust controlled processor, such that system/application 
processing proceeds in a trusted fashion. 

BRIEF DESCRIPTION QF THE DRAWINQ? 

Fig. 1 is a block diagram of an international cryptog- 
raphy framework, including a national flag card, a 
cryptographic unit a host system, and a network 
security server; 

Fig. 2 shows a trust web by which the framework 
service elements of Fig. 1 are interconnected; 

Fig. 3 is a schematic diagram showing the various 
elements of the international cryptography frame- 
work of Fig. 1. including exemplary processes that 
may incorporate an element of trust in accordance 
with the invention; 

Fig. 4 is a schematic diagram showing a trust 
boundary, as established between an operating 
system and a trusted computing base, according to 
the invention; 

Fig. 5 is a schematic diagram that shows a com- 
partmented execution to illustrate a separation prin- 
ciple according to the invention; 

Fig. 6 is a schematic diagram the shows a local 
execution of sensitive information to illustrate a 
locality principle according to the invention; 

Fig. 7 is a timing diagram showing behavior of a 
cryptographic unit during an operation stage 
according to the invention; 

Rg. 8 is a schematic diagram showing the flow of 
control for a trusted execution according to the 
invention; 

Fig. 9 is a schematic diagram showing local execu- 
tion of an adaptive kernel constituent according to 
the invention; 

Fig. 10 represents a positioning of a personal token 
in the context of trusted processing according to the 
invention; 

Fig. 1 1 is a schematic diagram showing the internal 
structure of a personal token and its relationship 
with a special trusted execution, i.e. the access 
method manager, according to the invention; and 

Rg. 12 represents the use of security controls, i.e. 



National cryptography policy often varies by indus- 
try segment, political climate, and/or message function. 
This makes it difficult to assign one uniform policy 
w across all industries for all time. Consequently, the flexi- 
bility of a cryptography framework that incorporates a 
national flag card is very attractive. The invention is 
therefore directed to resolving problems surrounding 
international cryptography. In a preferred embodiment 
is of the invention, a trusted processing element is pro- 
vided, for example in conjunction with a cryptography 
unit for a framework that may be used to support the 
design and development of any national policy regard- 
ing cryptography. Thus, the invention establishes a trust 
20 boundary such that both the use of cryptography and 
the use of a system protected by the cryptography are 
controlled in a trusted and tamper proof manner. It 
should be appreciated that the invention, although 
described in connection with an international cryptogra- 
ms phy framework, may be applied in any system environ- 
ment where a trusted processing element is desired. 

The cryptography unit in which the preferred 
embodiment of the invention is implemented preferably 
resides in an international cryptography framework that 
30 has four service elements, each offering different types 
of services. Fig. 1 is a block diagram of the international 
cryptography framework (ICF) 10, including a national 
flag card 12, a cryptographic unit 14. a host system 16, 
and a network security server 1 8. Three of the four serv- 
3$ ice elements have a fundamentally hierarchical relation- 
ship. The National Flag Card (NFC) is installed into the 
Cryptographic Unit (CU) which, in turn, is installed into a 
Host System (HS). Cryptographic functions on the Host 
System cannot be executed without a Cryptographic 
40 Unit, which itself requires the presence of a valid 
National Rag Card before it's services are available. For 
purposes of the discussion herein, the National Flag 
Card is also referred to as the policy because it provides 
the discipline that exerts a national cryptography policy 
45 and/or that is used to assert a trusted function. 

The fourth service element, a Network Security 
Server (NSS), provides a range of different security 
services including verification of the other three service 
elements, and thus acts as a trusted third party. M es- 
se sages encrypted using the proposed framework carry 
an electronic stamp identifying the national cryptogra- 
phy policy under which the message was encrypted. 
The Network Security Server also provides stamp veri- 
fication services for message handling systems. 
55 The ICF allows manufacturers to comply with vary- 
ing national laws governing the distribution of crypto- 
graphic capabilities. In particular, such a framework 
makes it possible to ship cryptographic capabilities 
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worldwide in all types of information processing devices 
{e.g. printers, palm-tops). 

It is advantageous to define and implement a 
trusted processing function within the confines of the 
framework or other processing system. Such function s 
should be based upon various underlying assumptions. 
Thus, to describe a security model which provides the 
necessary guidance to the structure, it is first necessary 
to list the assumptions made about the nature of the 
framework architecture. These assumptions dictate the io 
nature of the trust model. 

Composition. The framework consists of the four 
service elements cfisclosed by K. Klemba, R. MercMing, 
International Cryptography Framework, in a copending 
U.S. patent application serial no 08/401 ,588, which was is 
filed on 8 March 1995, interconnected with a trust web 
including a security domain authority (SDA) 71 and an 
application domain authority (ADA) 73, as outlined in 
Fig. 2. The framework is intimately built into the trust 
relationship set up between the application domain 75 20 
and the security domain 77, as separated by a domain 
boundary 79. 

Two different trusted elements materialize the 
active relationship in the trust web: the policy support 
and the cryptographic class of service - also referred as ss 
the COS. The policy support is a composite element 
which consists of a trusted element developed in the 
security domain, a policy (NFC), and a trusted element 
developed in the application domain, i.e. the crypto- 
graphic unit (CU). 30 

Coexistence. The framework coexists with an 
established network of interconnected physical 
machines/devices and makes the cryptographic dimen- 
sion of the existing network tangible. Each machine - 
host system - is the home for a number of trusted and 35 
untrusted applications all requiring access to a crypto- 
graphic service. Cryptographic services are made avail- 
able to the applications under a controlled policy. The 
policy is determined by the SDA. 

Existence state. Once the two trusted elements, i.e. <o 
the cryptographic unit and policy, are mutually authenti- 
cated and have set up a trust relationship, the policy 
support combined creates the existence state of the 
cryptographic mechanisms in the host system. 

Roles of the constituents. SDAs generate the policy 45 
support which materializes the ruling policy of the 
domain. The SDA can generate the policy themselves 
or delegate the right to an accredited entity of the 
domain - the national security server. They also can 
generate the policy . The delegation is not an endless so 
delegation chain, but rather a controlled chain with a 
limited list of entities. Generation of policy support ele- 
ments occurs in response to requests from an applica- 
tion user who requires the enablement of cryptographic 
mechanisms. 55 

SDAs also create and revoke the COSes and make 
them available to their ADAs through the means of a 
certificate structure. 



A cryptographic unit is manufactured by a trusted 
entity of the application domain. The trusted originator 
of secret information establishes yet another secure 
communication channel between the two domains, i.e. 
ADA to SDA. 

Administrative activities 76, 78 complement the 
trust web by providing the entities from both domains 
and the inter-domain relationship with consolidated inte- 
gration functions. 

Fig. 3 is a schematic diagram showing the various 
elements of the international cryptography framework of 
Fig. 1, including exemplary processes, e.g. DB Comm 
Runtime Lib 21, CU driver 22, and NFC driver 23, that 
may incorporate an element of trust in accordance with 
the invention. 

The invention provides a trusted processing ele- 
ment, for example in an international cryptography 
framework or other trusted processing application. For 
purposes of the disclosure herein, the element of trust is 
defined in accordance with ISO/1EC 10081 -1 , i.e. where 
element x trusts element y for some classes of activity in 
the context of a security policy, if and only if element x 
has confidence that element y behaves in a well-defined 
way that does not violate the security policy. For exam- 
ple, in the context of Rg. 3, the NFC driver 23 trusts the 
CU 14, H and only if the CU behaves in accordance with 
the policy dictated by the NFC 12. 

The trusted processing element is implemented in 
accordance with various principles, including: 

Separation - At any level of execution, clean sepa- 
ration of the security functionality from other func- 
tionality is employed to minimize the amount of 
functionality that must be trusted and therefore 
increase the level of trust that can be achieved. 
Hence, at one extreme end of the spectrum there is 
a singular execution of the instruction. Practically, 
systems or kernel implementations refer to an 
atomic execution element as a single task or 
thread. This principle leads to confidentiality in a 
system, but the separation principle is not consid- 
ered sufficient to fulfill integrity in most applications. 

• Locality - Any part of a system that is permitted to 
process information is able to corrupt that informa- 
tion. Therefore, preserving the integrity of the infor- 
mation depends on the level of trust of the 
constituent parts of the system that handle the 
information. As an application of the first principle, 
the trusted processing capability of a cryptographic 
unit as controlled by a policy card, becomes a 
trusted execution area where critical applications 
transform sensitive information. Such information 
uses protected mechanisms, i.e. envelopes 24, 25, 
to leave the trusted execution area or to join the 
user level task before local execution by the crypto- 
graphic unit. 
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Within the trusted processing element (for example, 
as applied to a cryptographic unit 14), the main CPU 
participates in processing trusted partitions that are 
controlled by the policy 12. 

Fundamental properties of the trusted processing 
element include: 

• Encapsulated single tasks; 

Use of closely coupled, reconfigurable kernel com- 
ponents; and 

Execution of adaptation policies in a secure vault to 
prevent unauthorized uses of privileges. 

Thus, the trusted processing element provides a 
trust controlled processor, such that system/application 
processing proceeds in a trusted fashion. 

It is a fundamental requirement of the International 
Cryptography Framework that a policy card - under any 
form factor, physical or logical - be present for a crypto- 
graphic unit to become functional. The International 
Cryptography Framework was designed to allow manu- 
facturers to comply with varying national laws governing 
the distribution of cryptographic capabilities. 

Basic Architecture Assumptions. 

Code prepared for execution by a cryptographic 
unit cannot be executed anywhere else; 

Code prepared for execution by a cryptographic 
unit cannot be modified; 

• Code prepared for execution by a cryptographic 
unit cannot be seen in the clear; 

Execution of code in the cryptographic unit cannot 
be preempted; and 

• Data manipulated by the cryptographic unit is exe- 
cuted locally. 

• A policy governs the trusted processing - physi- 
cal/logical retrieval of the policy decays the trusted 
processing. 

The problem of composition. 

The problem of composition is concerned with the 
kinds of relations that trusted elements can bear to one 
another in systems, including the security relevant prop- 
erties of trusted elements when in such relations and 
the inference that can be drawn about the security rele- 
vant properties of the composed system from the secu- 
rity relevant properties of the constituent elements. To 
be composaWe, trusted elements require some proper- 
ties be arranged into secure systems, especially where 



standardized properties make the implementation of 
trusted elements an easy task. 

Rg. 4 is a schematic diagram showing a trust 
boundary, as established between an operating system 

5 and a trusted computing base, according to the inven- 
tion. In the figure, the trust boundary 30 separates the 
operating system 34 from a trusted computing base 32. 
In this example, the trusted computing base contains a 
cryptographic unit 14 that is governed by a policy (not 

10 shown) in accordance with the international crypto- 
graphic framework described above. The cryptographic 
unit includes a crypto execution area 38 that performs 
cryptographic functions (for example, as described in 
U.S. patent application Cryptographic Unit Touch Point 

is Logic, serial no. , filed 

)• 

The cryptographic unit also includes a trusted exe- 
cution area 37 that is responsible for performing trusted 
processing. As discussed above, trusted execution 

20 occurs in accordance with certain basic architectural 
assumptions, e.g. the cryptographic unit is controlled by 
a trusted element, such as the policy. The trusted exe- 
cution area is typically a replica of an application mod- 
ule belonging to a host or external device token, or a 

25 system process being executed in a trusted computing 
base. The only difference is the controlled access to 
data and instructions due to a very tight connection to 
the policy. Because trusted processing as herein 
defined is a simple process, it is a non-interruptable task 

30 that has a single assignment to the process or CPU. 
Thus, it is not possible to replace the existing process, 
because that specific function of changing or switching 
context is under control of the trusted element, i.e. the 
policy monitor. 

35 The operating system typically executes various 
applications 39, 40, each of which includes one or more 
processes or tasks 41. Each application typically 
includes various partitions 42, each of which uses pro- 
tected mechanisms, i.e. envelopes 43, 44, 45, to leave 

40 the trusted execution area, e.g. to use remote proc- 
esses 46, or to join the user level task 41 before local 
execution by the cryptographic unit. 

The envelopes are an encrypted/signed bulk of 
data which may use any of various known standards. 

46 For example, in one embodiment of the invention an 
envelope employs the X/OPEN defined generic crypto- 
graphic services (GCS) encryption data structure 
belonging to an encryption handle, i.e. an application 
certificate credential is setup during the initial secure 

so association, e.g. create_CC. The specific handle is a 
session key that is encrypted with an application private 
key to ensure secure export/import/storage when it is 
not used in the trusted environment 

The cryptographic unit may include such compo- 

ss nents as software, virtual memory, and a CPU. ft is 
therefore possfcie for the cryptographic unit to store 
application programs in memory and page them over to 
a trusted computing base for trusted execution. Such 
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applications include various trusted modules (discussed 
in greater detail below), each of which typically has a 
signature assigned to it. Thus, the module has some 
binding to the task by itself, but specifically it has a sig- 
nature assigned to it, which makes it unique and verifia- 
ble in terms of authenticity and integrity. In contrast, a 
branching mechanism is no more than a standard con- 
trol structure or control function without any verification 
of integrity of the next instruction. The invention pro- 
vides a trusted element that prepares, as an example, 
some of the core components of a kernel, to make its 
behavior very specific. The prior art is not adaptive and 
cannot be reconfigured. Thus, the invention may be 
thought of as providing a trusted element that precondi- 
tions the application or the operating system to operate 
in a certain way in accordance with what the policy dic- 
tates. 

With the invention, it always is the case that trust 
lies in the boundaries of the trusted computing base, on 
one side of the trust boundary. As discussed in K. 
Wemba. R. MercWing, International Cryptography 
Framework, in a copending U.S. patent application 
serial no 08/401,588, which was filed on 8 March 1995. 
it is not possible to enter or modify a region that is 
secured by a policy. In the invention, the policy/crypto- 
graphic unit metaphor is used to establish a trust bound- 
ary within a process, such that trusted elements are 
used to control execution of a task or process within an 
application. Any attempt to stop or get rid of the pages 
from the application to the trusted computing base is 
detected by the trusted computing base and thereby 
disables (more accurately - deletes) any functionality 
afforded by the trusted element 

Thus, the operating system 34, e.g. MacOS, Win- 
dows, or Lotus Notes, may include a section of code 
across the trust boundary in the trusted execution area 
37, for example accounting code that charges a user for 
access to this system. In such applications, it is critical 
that this piece of code be executed. 

Implicit in the system is a trusted element, such as 
the policy discussed above in connection with the Inter- 
national Cryptography Framework, If the policy is 
removed the application could still run, but it cannot 
make use of the properties provided by a trusted 
v engine. In the accounting example above, the account- 
ing function would not run, with the result that access 
would not be allowed. 

In a system where cryptography is used, such as is 
shown in Rg. 4 in connection with the crypto execution 
area 38, the application may not be allowed to use cryp- 
tography in the absence of a policy, i.e. the trusted ele- 
ment. Thus, the application can run, but it cannot use 
cryptography. In this example, a cryptographic unit 
could be freely exported without regard to local laws 
regarding cryptography, but the cryptography could only 
be accessed in accordance with local laws when a pol- 
icy is installed, i.e. when the trusted element is present 

Fig. 5 is a schematic diagram that shows a com- 



partmented execution to illustrate a separation principle 
according to the invention. As discussed above, separa- 
tion requires that at any level of execution, dean sepa- 
ration of the security functionality from other 

5 functionality is employed to minimize the amount of 
functionality that must be trusted and therefore increase 
the level of trust that can be achieved. In the figure, the 
trusted computing base 32 is shown with a plurality of 
partitions 42, 44, 46, 48, 49, where each partition 

10 defines a process or task that must access the trusted 
computing base to assert an element of trust during 
execution of the process or task. By compartmentalizing 
execution into a plurality of partitions, each of which 
requires confirmation beyond the trust boundary, the 

75 trust function is separated from process or task execu- 
tion, such that execution of an application proceeds out-, 
side of the trust boundary, except for those partitions 
that assert trust which are separated from, but which 
assert trust for, the application (see Fig. 3). 

so Rg. 6 is a schematic diagram that shows a local 
execution of sensitive information to illustrate a locality 
principle according to the invention. As discussed 
above, any part of a system that is permitted to process 
information is able to corrupt that information. Thus, the 

25 trusted computing base must be secured. Therefore, 
preserving the integrity of the information depends on 
the level of trust of the constituent parts of the system 
that handle the information. By definition, the trusted 
processing capability of a cryptographic unit, as control- 
so led by a policy card, becomes a trusted execution area, 
i.e. the trusted computing base 32, where critical appli- 
cations 59, 60, 61, 62 transform sensitive information. 
Thus, locality requires that trusted functions be exe- 
cuted exclusively in the trusted execution area. 

35 The trusted processor allows the policy to provide 
different levels of privileges for various system users. 
Thus, a particular system responds to user access with 
different levels of privilege, based upon the particular 
policy, i.e. the level of trust is dictated by the policy A 

40 supervisor might have greater privileges than a clerk, 
and the owner of the company might have better privi- 
leges than the supervisor. The invention thus provides a 
trusted element that determines, for example, the secu- 
rity of an accounting function based on the policy, i.e. 

45 more authority requires less security and vice versa 

A critical element of the invention is that the system 
has physically separated the engine and the trusted ele- 
ment for example because it is desirable in some 
embodiments to be able to ship the cryptographic unit 

so internationally without export controls. As the crypto- 
graphic unit passes a border, it is not really a crypto- 
graphic unit because there is no way to make it work as 
a cryptographic unit until a user inserts a policy card. 
Thus, the cryptographic units are readily shipped across 

55 international borders because they do not contain cryp- 
tography when they cross an international border. 

ft should be borne in mind that the invention exploits 
this arrangement to advantage in other systems where 
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a separate element of trust is required and that the 
example given herein of the International Cryptography 
Framework and its constituent components is only pro- 
vided for purposes of illustration. For example, one 
embodiment of the invention combines both a crypto- 5 
graphic policy and privilege/identification data. When 
the trusted element. e.g. the policy, is joined to the cryp- 
tographic unit or other engine having the ability to 
access a trusted execution area, the cryptography 
within the cryptographic unit is activated in accordance w 
with the policy and the user/privileges is identified to the 
system. As soon as the policy is removed, not only has 
the user logged out of the system, but the cryptographic 
function is also gone. If somebody else accesses the 
system and tries to use it, it is not going to do them any is 
good because the cryptographic function is not working. 

The invention is thus useful for such entities as the 
national governments. For example, a government 
employee may be allowed to use a certain method that 
others are not allowed to use. As a consequence, it is 20 
not desirable to leave that method activated inside the 
cryptographic unit when the privileged user leaves. If 
the next user is not a government employee, then the 
method is not in the system. It is well known how to fal- 
sify authentication information. When practicing the 25 
invention, it is not sufficient to determine only if the user 
is a government employee before the classified method 
is activated. When the policy is inserted, the trusted ele- 
ment requires a continuing "conversation" between the 
task or process that cannot be duplicated because it is 30 
specific to the policy. Thus, falsification of an user iden- 
tity does not enable an application, for example where 
there are multiple partitions, each of which requires 
access to the trusted element. 

It should be noted that the policy may be joined to 3S 
the cryptographic unit in any of a number of ways. For 
example, they may be joined physically at a single loca- 
tion, or they may be joined electronically over a secure 
communications line. 

40 

Analysis of the Flow of Control. 

Envelopes are already the trusted shuttle as well as 
a corner stone of the encryption building block, provid- 
ing the vital gate enabling information to the touch 45 
points. Similarly, the envelopes transfer trusted execu- 
tion information to the policy monitor. The flow of control 
for the installation of the trusted processing policy is 
best understood by referring to the description of the 
cryptographic unit behavior set forth in U.S. patent so 
application Cryptographic Unit Touch Point Logic, serial 

no. , filed ), and by 

K. Klemba, R. MercMing, International Cryptography 
Framework, in a copending US. patent application 
serial no 08/401 ,588, which was filed on 8 March 1 995. ss 

Fig. 7 is a timing diagram showing behavior of a 
cryptographic unit during an operation stage according 
to the invention. For purposes of the invention herein, 



the cryptographic unit behavior is modified as follows: 

The cryptographic unit evolves to Step 7 (see, also 
Fig. 4, U.S. patent application Cryptographic Unit Touch 

Point Logic, serial na , filed 

) after a first successful heartbeat of the 

last installed encryption method. To consolidate the 
state, the cryptographic unit also changes the mode to 
Mode 8. In Mode 8. both the policy controlled trusted 
processing and the policy controlled encryption mecha- 
nisms are enabled. It should be noted that trusted 
processing can only happen while the controlled 
encryption is enabled. Conversely, as an example, the 
cryptographic unit may stay in Step 7 Mode 6 during 
one lifetime and yet switch to Mode 8 to enable trusted 
execution in another lifetime. For purposes of the dis- 
cussion herein, a lifetime is defined as the life execution 
of a cryptographic engine on one host system. As dis- 
cussed below, Step 7 - Mode 8 summarizes the time for 
installation of policies for trusted processing. A logical 
sequence number # is suggested to support the dis- 
course. 

Example of use: Certified Load. 

The following example is shown on Fig. 8. which is 
a schematic diagram showing the flow of corrtrol for a 
trusted execution according to the invention. This exam- 
ple shows an embodiment of the invention that provides 
trusted processing in the international cryptography 
framework discussed above. It should be appreciated 
that the following is provided only as an example of a 
preferred embodiment of the invention and that the 
invention is not limited to this particular embodiment. On 
the figure, each of the following steps is shown by a cor- 
responding numeral within a circle. 

Step #1 : The trusted communication is established 
between the policy monitor 70 and the policy 12, 
Le. two phases of the challenge/response for the 
cryptographic unit identification and the zero-knowl- 
edge exchange for the session key setup have 
been terminated successfully. 

Step #2: The policy monitor 70 has redirected the 
touch point data through the loader function (see 
US. patent application Cryptographic Unit Touch 

Point Logic, serial no. , filed 

). The installation of the touch point 

data for the last mechanism has concluded the dia- 
log with a successful heartbeat. 

Step #3: The header of the exchange envelope 
from the policy 12 to the cryptographic unitfcolicy 
monitor identifies the next contents of the envelope 
as a trusted execution credential. 

The following envelope content structure 
applies: 
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- adaptive kernel identifier (AKC1); 

- the privilege level which should be used to exe- 
cute the referred COSp; and 

• the system granted role(s) associated with 
such an application. 

Multiple iterations of envelopes may be neces- 
sary to install all the trusted AKCs. 

Step #4: An application credential is presented 
through the API with a certified COSp credential. 

Step #5: The trusted adaptive kernel constituent is 
launched by message passing, thereby enforcing a 
specific privilege level. 

Step #6: Various subAKCs are requesting some 
decryption of keying material, executed locally. 

Step #7: A specific bulk of data is referred during 
the execution of the application, requiring the use of 
some registered import/export mechanism. 

Step #8: The application execution concludes with 
a successful encapsulation of some keying informa- 
tion to be retrieved in a further invocation. 

Hardware protected space. 

Fig. 9 is a schematic diagram showing local execu- 
tion of an adaptive kernel constituent. In the figure, a 
trusted processing CPU is governed by adaptive 
processing policies for the kernel constituents. Similarly, 
such constituents require invocation of subconstituents. 
This is shown on Fig. 8 for AKC1 , which includes a priv- 
ilege level, a method and information gathering (which 
may involve message passing or shuttling), a class of 
service granted by the ADA, and a role. The mechanism 
of the embodiment shown on Fig. 9 is simitar to that 
described above in connection with Fig. 8. 

Execution of adaptation policies for adaptive kernels. 

New generations of kernels provide specific sup- 
port for adaptability, configurability of their basic compo- 
nents, and the supply of required dedicated run-time 
behaviors to critical applications, collectively referred to 
herein as personalities. Applications use various kernel so 
resources, e.g. scheduling components, synchroniza- 
tion components, threads, memory handlers, exception 
handlers, and interrupts. Earlier research has demon- 
strated that heavy transactions applications, as well as 
parallel applications, often require dynamic process ss 
migration and load balancing. To meet the fundamental 
properties required for such resource management 
components of constituent products require standard 



interfaces, data formats, and protocols. 

Kernels provide resources to applications such as 
the scheduling components, synchronization compo- 
nents, memory handlers, and exception handlers. All of 
these components define a specific real run-time 
behavior for an application. One aspect of the invention 
(discussed above) defines personalities per application 
which are in fact a translation of a policy. A policy 
installed in the cryptographic unit can constrain the per- 
sonality of an application, such that an application acts 
a certain way based upon the policy. 

For example, the policy can constrain the personal- 
ity of the cryptographic unit by configuring synchroniza- 
tion mechanisms, interrupts, and exception handling, to 
either facilitate or prevent an application's use of privi- 
leged modes of operation. If the operating system has a* 
kernel function, e.g. a print module, then a print process 
may be inhibited by the policy, Le. the user can look at 
certain information but the information cannot be 
printed. Likewise, the policy can deny the user access to 
a server. With regard to Figs. 5 and 6, one of the parti- 
tions might be in the print driver, such that the print 
driver must access the trusted computing base to exe- 
cute. Thus, if the policy denies printing capability, then 
the print driver is not executed. 

The following provides an example of an application 
of the secure distributed processing capabilities for a 
personal token (see Fig. 10). This example introduces 
the concepts of accessing personal tokens 90. such as 
smart cards. Smart cards gain more and more impor- 
tance in a wide range of industry sectors. While being 
designed for keeping simple and small amounts of infor- 
mation securely, greater capacities of data storage and 
better methods of accessing that storage are required 
for applications to fully take advantage of the personal 
token. 

The key challenges are the limited capacity of the 
personal token, which leads to a trade-off in functionally 
versus capacity. Alternatives can been sen in distribut- 
ing the processing elements across the trust web using 
the adaptive kernel constituent (AKC) model as devel- 
oped earlier. 

The following describes a method for implementing 
a higher level structured access method, such as SQL, 
or invocation methods such as applets, for very small 
environments. It develops a framework which allows the 
secure distributed processing between the personal 
token and the cryptographic unit installed in the host 
system. 

Three major scenarios can be defined from the 
principles of separation and locality introduced above: 

Scenario 1 is a special execution policy for a stor- 
age manager. 

Scenario 2 is the use of the eight steps decomposi- 
tion (discussed above) where the target application 
is an applet 
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• Scenario 3 is the explicit separation of data and 
method, where the data resides in the personal 
token, and where the execution method belongs to 
the trusted processing in the cryptographic unit. 

5 

Because scenario 2 has already been discussed 
above in connection with Fig. 8, no other extensions are 
requested. 

Scenario 1 requires an additional introduction. 
Three major building blocks are part of the solution. io 

Application. The application is the element that con- 
nects to the personal token to access stored informa- 
tion. The application needs to establish a mutual 
authentication with the token to assure the authenticity 
of the date exchanged. is 

Access Method Manager. The access method man- 
ager provides a high level abstraction, such as the SQL 
language, to the application. All requests coming from 
the application are expressed in this higher level access 
method. 20 

. Specific access policies can be installed into the 
policy manager block, shown on Fig. 11, which help 
enforce the only use of SQL command classes (e.g. 
DELETE USER, CREATE KEY and UNLOCK) for a 
specific administration application where the user has a 2s 
role of administrator. To be specific, the AKC_ invoca- 
tion field allows the execution of command classes 
delete_user, create Jtey, and unlock. No COS field is 
assigned to it H no encryption of data is required. 

Storage Manager. The storage manager is the ele- so 
merit that is implemented inside the personal token. The 
main responsibility of the storage manager is to manage 
the information stored within the personal token. 

The same principle applies to the control of the 
movance of encrypted data, including their transfer, 35 
conversion, replication, and encrypted storage. The 
application with AKC_ invocation field allows specific 
movance functions with a COS field set to encrypted 
storage. 

Scenario 3. which is represented by Fig. 12, has 40 
another building block: the security layer. 

In the traditional approach, where every component 
exists inside the personal token, the security boundary 
is at the access method level. The invention provides a 
method and apparatus that breaks with this division by 4S 
introducing a security boundary that is at a lower level. 
As a consequence, sensitive structural information must 
be exchanged between the access method manager in 
the host system and the storage manager in the per- 
sonal token. so 

All message traffic between the personal token and 
the access manager must be exchanged in encrypted 
form, e.g. the envelopes. Cryptographic services must 
be available on each side of the connection. Fig. 12 
shows a system that uses a cryptographic unit on the ss 
host system and the cryptographic services imple- 
mented in the personal token for this purpose. 

During connection time, both parties need to 



authenticate each other, the access manager must have 
the structural information before it can build an access 
request. The access method manager sends a request 
to the personal token to establish the connection. The 
personal token replies with a challenge and the struc- 
tural information needed by the access method man- 
ager to build a request for the storage manager. 

After the download of data and structural informa- 
tion from the personal token to the execution zone, 
using the envelopes, the trusted processing can engage 
privilege instructions as specified in the access method 
manager application. This scenario uses the AKC_ priv- 
ilege field to control the execution of proper action on 
the data loaded through envelopes. 

Key to the invention is the fact that the trust bound- 
ary cannot be breached. While this boundary can be 
physical, electrical, or logical, the trusted element, i.e. 
the policy, establishes the trust boundary by providing a 
hardware element that cannot be duplicated because of 
the manner in which it is manufactured and personal- 
ized. While the trusted element can be any of several 
secure devices or techniques, the preferred embodi- 
ment of the invention exploits to advantage the proper- 
ties provided by the policy described in K. Klemba, R. 
MercWing, international Cryptography Framework, in a 
copending U.S. patent application serial no 08/401 ,588, 
which was filed on 8 March 1995. 

Some of the applications to which the invention may 
be put include, trusted login audit execution, creation of 
audit-logs, trusted configuration management, network- 
ing and system infrastructure, application management, 
security authority management, application authority 
management, policy cards management, and consumer 
cards, e.g. personal tokens. 

Pecay Functfpp 

Each of the messages sent between the crypto- 
graphic unit and the policy is encrypted using a key that 
is constantly changing. This allows the system to create 
a progression that cannot be interfered with because 
the key is always changing. The value k j (where kj is 
one of the messages) is equal to a function of the ses- 
sion sequence number (RN). These messages began 
with a random point e.g. 1010, which is a random 
number that was the first sequence number sent 
between the policy and the cryptographic unit The pol- 
icy sends a response to the cryptographic unit which 
increments the number, i.e. 1011. The system contin- 
ues sequencing from this random point. The function of 
the value k f is a function of that random number and K 
where k is determined during the initialization phase (as 
discussed above) and is a unique key that the policy 
and cryptographic unit now both share. 

To know the key at any point k j( or to predict that 
key, it is necessary to know the serial number of the 
message, RN, and k, the original number. Additionally, 
the function has a decay value. For example, suppose 
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the policy and cryptographic unit have been in commu- 
nication for quite a while and are up to the number 2084, 
i.e. the value of RN. Where an interloper has captured a 
lot of the messages and wants to come back and get the 
first message, tf the value substituted is more than a 5 
delta of 10 away from the actual number, the function 
does not work. Thus, kj is only valid when RN is less 
than or equal to 10 from RN. 

With the decay function, the policy and crypto- 
graphic unit may be passing a message of any type that 10 
is encrypted using kj.lt may be possible with a brute 
force attack on one message to go off and work for five 
days and break one message to get k { . However, that 
was what the key was two clays ago. Knowledge of that 
key and even knowledge of this function cannot be is 
reversed to identify the value of k. Even if k and k - t are 
known, the value calculated is more than 10 off from 
current value. 

A value such as 10 is chosen in the preferred 
embodiment of the invention because a legitimate sys- 20 
tern could fall out of synch by a jitter due to. for example 
a power failure or if someone snaps the policy out just 
before they were able to update the number in their 
static RAM. Suddenly the system is powered back on, 
but the system never goes back to zero again. When the 25 
is powered back on, it is expected that the system starts 
off with kj. However, that value could be off, so the 
number is modifiable in the algorithm, e.g. by 10. 

An important aspect of the invention is that the sys- 
tem trusts the policy, but does not really trust the crypto- 30 
graphic unit Every now and then the policy may change 
the sequence number. Thus, the policy may normally 
increment the sequence number one by one by one, 
and then every now and then it issues another random 
number. When it does that, the cryptographic unit ss 
receives the number in the message because the mes- 
sage would have been encrypted using k j, which syn- 
chronizes the system. When suddenly the other side 
sees the sequence number jump, the message received 
is valid because it was in the stream, it was encrypted 40 
with the right next key, only the sequence number is tak- 
ing a jump. The cryptographic unit follows that jump 
because its about to send a message back to the policy. 
So, the system intentionally jump over the decay value, 
e.g. 10, periodically just in case the value was 45 
decrypted before the tenth message. This jump only 
comes from the policy. A cryptographic unit knows that 
from time to time there is going to be a jump, but if the 
policy ever sees a jump it is going to work. Further, the 
interval for the jump can be totally random and the so 
amount of jump can be up or down a any which way. 

Although the invention is descrfced herein with ref- 
erence to the preferred embodiment one skilled in the 
art will readily appreciate that other applications may be 
substituted for those set forth herein without departing ss 
from the spirit and scope of the present invention. 
Accordingly, the invention should only be limited by the 
Claims included below. 



Claims 

1 . A trusted processor, comprising: 

a process (41) that executes a task within a 
system, said process having one or more parti- 
tions (42, 44, 46. 48, 49; 50. 52. 54, 56. 58) that 
define trusted modules; 
a trust boundary (30) established by a trusted 
element (12); and 

a trusted computing base (32), including a 
trusted execution area (37); 

wherein said trusted computed base is 
separate from said process, and wherein said 
trusted modules are executed locally within 
said trusted execution area. 

2. The trusted processor of Claim 1, said trusted ele- 
ment comprising: 

a policy (12). 

3. The trusted processor of Claim 2. wherein said pol- 
icy (12) implements a processor personality. 

4. The trusted processor of Claim 3, wherein said per- 
sonality defines a level of trust and/or privilege to be 
afforded a user of said trusted processor. 

5. The trusted processor of any of Claims 1 to 4, fur- 
ther comprising: 

a envelope (43) for conveying information 
across said trust boundary. 

6. The trusted processor of any of Claims 1 to 5, fur- 
ther comprising: 

a cryptographic unit (14); and 
a policy (12); 

wherein said cryptographic unit is con- 
trolled by said policy, said policy comprising 
said trusted element. 

7. The trusted processor of any of Claims 1 to 6. said 
trust boundary (30) comprising: 

a physical, electrical, and/or logical barrier. 

8. The trusted processor of any of Claims 1 to 7, said 
trusted element (12) comprising: 

a hardware element that cannot be duplicated 
because of the manner in which it is manufac- 
tured and/or personalized. 

9. The trusted processor of any of Claims 1 to 8, 
wherein said trusted element (12) controls the use 
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of cryptography within said trusted execution area 
(37). 

The trusted processor of any of Claims 1 to 9. fur- 
ther comprising: 5 

a challenge/response mechanism (70) for 
securing communications across said trust 
boundary. 

10 

11. The trusted processor of Claim 10. said chal- 
lenge/response mechanism (70) further compris- 
ing: 

a decay function for dynamically altering a chal- is 
lenge/response key. 

12. The trusted processor of Claim 1 1 , said decay func- 
tion further comprising: 

20 

means within or associated with said trusted 
computing base for randomly altering said 
challenge/response key. 

13. The trusted processor of Claim 1 1 , said decay func- 25 
tion further comprising: 

a fixed value offset that defines a range of 
acceptable values for said challenge/response 
key. 30 

14. The trusted processor of Claim 10, wherein said 
challenge/response mechanism (70) is non-repeat- 
ing and/or non-predictable. 

35 

15. The trusted processor of any of Claims 1 to 14, 
wherein said processor further comprises: 

at least one application having at least one 
adaptive kernel (AKC), wherein said adaptation ao 
is in response to a personality imposed by said 
policy. 

16. The trusted processor of any of Claims 1 to 15, 

■ wherein said trusted element is a personal token 4s 
(90). 

17. The trusted processor of any of Claims 1 to 16, 
wherein said trusted element (12) is a tamper- 
resistant smart card. so 

18. The trustetd processor of any of Claims 1 to 17, 
wherein said trusted computing base (32) is sepa- 
rate from data; and wherein said data are collected 
and/or transferred to said trusted computing base ss 
for processing. 
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